I think we all in Debian agree that the current discussion and the votes are a cruel mess. But if anyone wants to blame anyone else for this, please consider some facts: The outcome of the vote depends on what is to be voted on. If the vote is "Eat shit or die" a majority of people might choose the shit. That's why our constitution allows everyone to amend the vote, to offer more options, so that people can vote for what they actually want. This might get messy, especially if the process is chaotic. It can only work if people take the time and consideration to discuss the suggestions long enough to get to sane values. But if you haste it will get messy. That there is so much haste currently is also our all fault. Of course if more people had worked on the firmware issues, we would not have this problem. But this is not the fault of one side. The other side could have worked on that too. Some "But I have nothing against firmware in the kernel." is as little an excuse for not working on it as "I do not need kernels for hardware without free firmwares". Because the outcomes of the last votes for sarge and etch made clear that just having the stuff in the kernel is no solution. Everyone that did not propose a GR to allow non-free firmware more than half a year ago and did not work on easing things for users needing non-free firmware has either to admit that it is also his fault by omission as much as those not wanting the firmware in there and not having done more to get rid of it. Or you have to admit you willfully did nothing to now take the release hostage for your goals. That said, I also want to speak against the "lenny without firmware will be totally unusable". I didn't look at the details. But when I in the last half year had some servers that needed some firmware, that was not even in the kernel and on the installation media, I was extremely surprised how easy it was to put it there and how anything went correctly without thinking much, the installer just copied the needed files directly on the installed system. The initrd generator must have included that somehow (for it was a firmware for the sata card, and it actually boots). And I think it might not even be needed on the installation media, but might also be inserted by some other means. (But putting it in the initrd of the netboot installer was just so easy, that I tried nothing else). Some post-scriptum: I personally would have deemed it more clean to have Peter Palfrader's proposal not made to amendment of the other vote. But if it had been handled otherwise, I definitely would have suggested an amendment to it (and perhaps some others, too). So do not think it would have made things much faster or easier to grasp. Another post-scriptum: It's the job of our secretary to protect and interpret the consitution. The only thing looking at the current discussions is why political partisans in some western countries not yet got to the idea of recalling judges whose job it is to protect the constituion. Perhaps because in that setting it would sound just too absurd...

It's a longstanding bug that java programs show empty gray windows when being used in many window managers. As there is OpenJDK now, I thought: It's free software now, so look at it and perhaps there is a way to fix it. As always, looking at java related stuff is a big mistake, but the code in question speaks volumes. The window configure code has:

        if (!isReparented() && isVisible() && runningWM != XWM.NO_WM
                &&  !XWM.isNonReparentingWM()
                && getDecorations() != winAttr.AWT_DECOR_NONE)  
            insLog.fine("- visible but not reparented, skipping");
            return;
         

and if you wonder how it detects if there is a non-reparenting window manager, it does it by:

     static boolean isNonReparentingWM()  
        return (XWM.getWMID() == XWM.COMPIZ_WM   XWM.getWMID() == XWM.LG3D_WM);
      

Yes, it really has a big list of 12 window managers built in for which it tests. And this is not the only place where it has special cases for some, but it does so all the time in the different places. But what Sun did not think about: There are more than 12 window managers out there. And with this buggy code it would need a list of every single one not doing reparenting (like ratpoison as when I read the bug reports correctly also awesome, wmii and a whole list of quite popular ones, too). Or it means that you are not supposed to run graphical java applications unless you use openlook, mwm (motif), dtwm (cde), enlightenment, kwm (kde), sawfish, icewm, metacity, compiz or lookinglass or no window manager at all. As I did not yet had realized that the old workaround of AWT_TOOLKIT=MToolkit no longer works in lenny before reading some debian-release mail, which means I haven't use any graphical java program for a long time, it seems I have decided for the latter. P.S.: I've sent a patch that one can at least manually tell java that one would like to see windows' contents as b.d.o/508650

Trying to get prepared for lenny, the new iceweasel annoys me more and more.

• Problem 1: How do I globally set a program to use for mailto: links?
  The old solution no longer works, and the only workaround I found is placing a mimeTypes.rdf with the right contents to /etc/iceweasel/profile, but that of course only works for new accounts, not when upgrading accounts...
• Problem 2: Is there a way to get the Xprint interface of iceweasel back?
  It still suggests xprint, but I see no way to not get those gtk printing dialog boxes. Those of course only show "Print to file" because I am using lprng and someone decides to disable the lpr backend gtk by default. (Those printing backends modules in gtk seem like a nice thing at first, I could easily write one to show the printers in /etc/printcap and have controls for all the options of the printer's PPD file in there, but it only helps to get the dialog better). But the postscript it creates is just broken beyond description. No need to speak about doing color all the time (looks like there is no way to tell cairo to make a surface grayscale), or embedding all the fonts, but it tries to do the distance of characters on its own and miserably fails so. The fonts it embedds also have some strangenesses, or the pswrite method of the new ghostscript has problems, too.
  Another problem with the gtk print dialog in iceweasel is in the print setup dialog box. It always defaults to letter, and I found no way to globally change this. Here most likely the fault is somewhere in the glue code, giving that a first glance looks really like someone only knowing letter and executive wrote it...
• I'm sure there were others, but those I forget over the more urgent ones...

As I wrote in blog item 29 there are many ways to break your debian/rules file. As I grew of seeing those and many more, I decided to write a lintian test for this. Getting that finished will still need several days, as the general Makefile syntax is quite intresting in detail, and lintian is written in perl thus so have to be tests. It's quite intresting that the different cases when variables are resolved and when not seem to quite firmly force an specific way to parse it. (And relearning perl when I so successfully unlearned all parts of that language in the past make it not much faster). Anyway, the reason I'm blogging is to give you already the results of one particular test a preliminary version gave when running over the lintian lab: It's checking for targets with -stamp in them that are phony, as that makes no sense. It will either cause configure or make run multiple times via build, wasting buildd cycles or even make the build more unstable, or just indicates needlessly complex Makefiles (having an install target that invokes an install-stamp target that does not actually produce a stamp file just makes the Makefile longer without doing anything at all but confusing readers). You can find the preliminary results for that test at http://people.debian.org/~brlink/debian-rules-phony-stamp-file.log. I looked at some randomly choosen results and did not find a false positive. As that list was produced by the last runable version which did not yet look at variables, I guess the list will only increase.

When recording changes in some software there are basically three approaches, with their different advantages and disadvantages.

• One approach is just record modifications chronologically. Each modification is just a little diff (or some glorified variant of diff, or if you insist something that is no diff but just has some similarity). Advantages are:
  • It keeps itself out of the way. You just do modifications and store them somehow one after the other.
  • You can reconstruct all past points, so can regain missing documentation by looking at the evolution in time.
  So it is no surprise that essential every tool (i.e. all the VCSes) to handle non-packaging work on software essentially uses this way. If you have an canonical other source for the software (like an upstream for an package), it has quite some severe drawbacks:
  • Reviewablity does not scale. While every single diff can easily be reviewed, the mass is not. Most changes are relative to past versions of the software. If something introduces a problem or and upstream change introduces a problem with that, the fix might only show up years later, separated by tons of other changes in between. (The effect especially with changing upstream always depends a bit on the later merging, but the worst case is still the same).
  • For the same reason changes cannot be easily extracted. Single commits usually are fine, but what of those past changes is needed to make some specific change in the functionality is easily lost after some time, some improvements and updates to new upstream versions. The whole approach degenerates to having a single large .diff.gz file of the package. (Except one has a bit of history recorded, so when sorting out the stuff in that diff one can better guess what effect a single unattributable line has).
• The next possibility is to store modifications sorted by topic and against upstream (either as .diff files relative to the upstream source, as topic branches, or or or). Advantages:
  • As you have to send the patch upstream anyway, you have to create such an patch initially, anyway. Also each is in a format that if upstreams wants to apply a single one, each is in the correct format for this.
  • Branches relative to a (relatively) fix point are usually use to store in VCSes.
  • When other people want to pick a subset of those patches, they only have to do the merging, and not dismerging with the missing ones first.
  On the other hand, there are some disadvantages with this:
  • As the differences are relative to the upstream code, multiple patches are in general not applicable without additional merging.
  • Because of this, those patches cannot be used to generate the source to build the Debian package.
  • Thus those patches by itself are never directly used, unless the maintainer regularly tests them, they are essentially untested and will see bitrot.
  • As those are not the changes to the package because of the missing merge, they are nice for a cursory review, but if you want the review the actual changes, you need to review the merged variants.
• Last but not least, there are stacked patches, i.e. patches that are supposed to be applied in a specific sequence. Advantages:
  • The patches itself are actually used. Thus they get wide testing and bitrot cannot happen that easily.
  • Equally, reviewing the actual changes can be separated into the different patches, as connected changes are next to each other and the files describe the changes without pitfalls in merges.
  • If someone else wants to use multiple patches from the start of the sequence, no merging is necessary. They can directly be applied.
  Given these advantages, it is no big surprise that all Debian specific patch management tools (like dbs) and other programs to deal deal with multiple patches against other people's code (like quilt) use this approach. Though there are also some disadvantages:
  • Ordering patches is not important. Only unrelated patches can be skipped to have later patches applied cleanly, so ordering needs to predict what patches are more likely to be used by other people.
  • Testing only happens for the whole stack. If some match modifies parts that a later patch removes, bitrot can still happen.
  • Extracting those patches from the currently available VCSes is not trivial.

So the format most suitable to Debian packages (stacked patches) is the total opposite of a format most suitable when you are upstream yourself and nothing is suitable for everything. There are many different thinkable ways to combine the different things to get more of the advantages, though many are a bit lacking (like storing quilt series in a VCS as text files), not yet possible or non-trivial with the current tools. Hopefully the future will improve that.

Looking at the current discussions, I'm wishing some people would calm down a bit. It's always impressive how some things switch sides like pendulums. First of all, Debian already is centered about packing software and not developing them. We already have the rules and policies and methods in place. Our policy states:

If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.

And our source format shows how important marking the difference is to use: We have explicit .diff.gz files to contain them. The differences are not hidden in same Version Control System (like BSD) or in propretary formats (ever tried to unpack a .srpm without rpm or without downloading some magic perl script?), but in a simple universal understandable format. That said, please remember we are a distribution. Our priorities are our users and not the whims of software authors. We have to find the middle ground between harmful and necessary changes. Patching software to abide the FHS, to allow the user choose their editor or browser in an common way or any other thing to form a coherent set of packages is no bug in Debian, it is a bug in upstream to not allow this at least via some configure option. We have neither the manpower nor the job to rewrite and fork stuff to a usable state, though. Thus we have to keep to upstream and hope they will include our modifications or forward-port them to every new release. Thus, we need both: We need to patch (and in general, the worse the software from a distribution's point of view or from a general point, the more of this we need. This does not necessarily hold in the other direction, though.). And we need and want to show what we change. So our users can find out how exactly the software we ship is different. And so other people dealing with the same software can profit from our changes. (After all, free software is about "giving back" a lot.). And of course maintainer change over time and we want the new one understands what the previous one did. That said, there is of course things that can be improved. But as with all improvements there are things that improve and there are things where nothing is worse than good intentions. Adding more thing to keep in sync is almost always a bad thing in the long run. The easiest way to keep things accessible is to use stuff actually used. I think any additional place to track patches will be futile. A good interface to view the .diff.gz files in our archive in some browser, on the other hand, could hardly get unuseful. The format of a single .diff.gz is of course also improveable. Things like a quilt-like standardized patch series look like a very good idea to me. But the format is of course also very downgradeable. Storing VCS formated information for example, tempting as it is, spoils two very important points:

• universal readability is lost. Everyone coping with software can work with patches or patch series, no matter what tools they use.
• visibility of changes is sacrificed for history. Every single VCS I ever saw primarily coped with history. Even patch based ones represent changes in time and not by itself changes by topic.

And of course, a lot can be improved by just using some rules more strictly. Not using a pristine tarball or a proper subset of one where the first is not possible should not be some mere ignorable non-conformist behaviour, but seen as the serious problem it is.

Do you want know what is really stored in your gpg keyring? Or do you want to store your keyring into a VCS? Or you you want to be able to delete signatures or other data from a keyring without having to use gpg's absurd interface? If you do, then you might want to look into a little program I started for this purpose. It's still quite alpha, but for some uses should already work. And if you test now and give some feedback, it might develop more in a direction you need. To give it a test:

cvs -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/gpg2txt checkout gpg2txt
cd gpg2txt
./autogen.sh --configure
make
less README
man -l gpg2txt.1
./gpg2txt -o test ~/.gnupg/pubring.gpg
less test
./gpg2txt --recreate -o pubring.gpg test

Till today I thought make was a very simple concept, but looking at other people's debian/rules files I start to lose that faith. So let's begin with some basics (as I guess many reading this are maintainers for Debian packages, and you might need some of this knowledge): As you will already know, the most important part of a Makefile is a rule. Each rule is there to produce something and has prerequisites, i.e. things that have to be done before. So far so simple. When you think about this way, the first pitfall is already no pitfall anymore:

   build: patch build-indep
   build-indep: build-indep-stamp
   build-indep-stamp:
   	$(MAKE) doc
   	touch build-indep-stamp
   

There are two mistakes in this. First of all, the clean is only called on ./debian/rules build, but not on ./debian/rules build-indep. And then patch is only called by the build target. But what you really want is that the source is patched before you do something, so it is something do be done before build-indep-stamp. The pitfall with this error is that you will not see it most of the time. As make usually processes targets in the order it finds them, it usually runs patch first. Except when you have multiple processors and tell make to make sure of them (and even then there is a chance it might work as the command to run first is fast enough) or if someone trusting on what he learned about make does call ./debian/rules build-indep-stamp build. I guess a reason one sees this so often is the next pitfall. Most likely previous the following was tried:

   build-indep: build-indep-stamp
   build-indep-stamp: patch
   	$(MAKE) doc
   	touch build-indep-stamp
   patch: patch-stamp
   patch-stamp:
   	whatever
   	touch patch-stamp
   

The pitfall with this is some new concept. The problem is that the patch rule is phony. A rule is called phony when it does not produce the target it claims to do. The classical example is a clean target. You do not want that a clean target creates a file clean and the next time it is called says "already everything done". Targets get phony by telling make it is (via .PHONY:) or by just not producing the file it tells to produce or (suprising to many, it seems) by having a phony target as prerequisite. In the above example the patch target gets implicitly phony, as it does not produce a file called patch. Thus after having build the source and calling binary to create packages, this will most likely in some way depend on build-indep-stamp. But when make thus looks at build-indep-stamp to decide if it already there and even though it sees the file produces there with the touch command, it cannot determine if that is up to date. It depends on patch and there is no file called this, thus make must assume it is not up to date, thus build-indep-stamp has become effectively also phony, in the sense of having to be called every time it is depended on. (In case you have not noticed, the fix would have been to make build-indep-stamp depend on patch-stamp instead or to go without patch-stamp and make patch the file to be generated). Thus, you can put as many -stamp files as you want in a row, as long as you have a single phony prerequisite in them, it is all void.

A hijack of an important package makes me always uneasy. But reading the next two messages to the debian-dpkg list, which I can only read as "oh, I broke make dist. But why should I follow sane practises, all hail my workflow" and "oh, I brake Changelog, that's on purpose because I consider it a bad idea, if you want it make write some scripts to generate it" does nothing to make me believe such a person can be a good maintainer.

If you ever wondered, why exim4 needs so long to start when you have no net access, though you were sure that configured as satellite for a smarthost it should have nothing to lookup as the smarthost in in /etc/hosts, you might just have forgotten to put a

     disable_ipv6 = true
   

in your exim4.conf. (I'm not sure, but that might also help to actually deliver mail to hosts which also have ipv6 addresses on servers with outgoing smtp when you forgot to blacklist the ipv6 module).

I don't know why some people always shout censorship when it's about what is acceptable behaviour and what not and about what things people want to be assosiated with and with what not. (Must be some relative of Godwin's law (the original, not the "you lost" usenet-variant)).

I personally do not care only little about what happens in irc-channels I'm not in. I don't know what happens in this this special channel starting the discussion, and I don't believe any anedotically examples can make a big difference. (Humans err, sometimes in tone, and even some hundred examples of wrong tone in some backyard alone is nothing I care much about, as long as it is nothing that would be a criminal offense if done in more public places).

What I absolutely dislike is any form of communication forum - especially those that could be associated with me - to be declared as a place where foul behaviour (to which I count sexism) is acceptable and even worse to be accepted as norm. (Why didn't anyone shout "censorship" at the "Love it or get the fuck out of here"? Perhaps there is some correlation between views of the world I don't understand).

By the way, there are places where I feel personally offended as a victim of sexism by a statement like "men are pigs". For example in a discussion about sexism. (I know, I know, it might not be sexism according to some definitions, but I see no reason to not use the word or not dislike it just because the forcing into gender roles is done by members of the same sex as opposed to to members of the opposite sex.)

The story seems to have started with Damog supporting sexism and xenophobia in Debian, followed by Bernhard’s comment about that not being tolerable under Debian’s flag. Aigarius replied kinda shocked that stopping verbal abuses and violence would be censorship. AJ clearly explained the reasons why that shouldn’t be tolerated in Debian, but Aigarius seems to keep thinking that poor jerks are being discriminated when they’re not allowed to insult us. Wouter seems to be tired of the whole topic. Am I missing any chapter? Now my turn: We are on the right way. Since the Debian-Women project started, we have being able to achieve a friendly and non-sexist environment inside Debian, which is something that I’d really like to keep. It doesn’t really mind that a couple of people try to go back to a hostile environment. Trolls just do exist, I guess, but they are not representative of the general feeling of the people inside Debian. Damog, I won’t get the fuck out of here, like it or not. It seems to me that it’s just a couple of you who are happy to be in such an aggressive environment as the one you’re promoting. For what I know, most of Debian people are happy to live in peace. You don’t have social life? You don’t like it? That’s your problem, dude, but don’t ask us to leave ours. I respect you, you know I have always done. I’m just very disappointed with your comment. Really. Making fun of other people’s problems and traumas is simply bullying. I hope you think about it. For the rest of Debian, keep up the good job. Right now my feeling is that the level of sexism, racism, ageism, homophobia, hostility and unfriendliness in general inside Debian development’s world is below the average in the Free Software world. It’s nice to be there, and I’m really proud of belonging here, which is something I cannot say about every group in Free Software. I’d like to keep it that way. Sorry for the aggressiveness in this weblog entry.

I hope I am not alone, but a community stating "Of course we are sexists" (if this is a expression of more than a individual) is in my eyes nothing that should be allowed to have debian in its name, even if it is marked as inofficial (and especially if it says "Love it or get the fuck out of there.").

Can't people find a way that is neither pseudo-moral pressure of some "political correctness" nor childish increasing of self-esteem by showing everyone how "political incorrect" you dare to be.

Playing around with awk and graphviz can lead to nice but usually totally useless graphs:

   #!/bin/sh
   if test $# != 1 ; then echo "Missing argument!" >&2 ;  exit 1 ; fi
   FILENAME="$(tempfile -s ".ps")"
   ldd "$1"   mawk &aposBEGIN print "graph deps  " END print " "  function dump(name,binary)   system("objdump -x " binary "   grep NEEDED   sed -e \"s#.* # \\\"" name "\\\" -- \\\"#\" -e\"s/$/\\\"/\"")  BEGIN dump("&apos"$1"&apos","&apos"$1"&apos")  /=> \//   dump($1,$3) &apos   dot -Tps -o "$FILENAME"
   gv "$FILENAME"
   rm "$FILENAME"
   

I had written a little script to create a local config, so one can as user run everything (short of actually installing packages) as user. (Which is quite useful to download all packages needed to update an offline system or to install something on that. Of course one needs that system status file for that).

When updating that script to the apt now checking signatures I had to realize, that the file with the keys to look for in Release.gpg files seems to be no file. At least it&aposs location is not stored in apt&aposs Dir section, where it would be nicely adapted to changes of the other directory, but is stored as a simple value elsewhere, so it needs an additional overwriting.</rant>

Anyway. The updated script can be downloaded here, just in case it might be of interest to anyone else.

Bernhard R. Link blogs about LDAP addressbooks in Thunderb^WIcedove, and mentions:

Also don't be confused by no records shown in the new addressbook. I guess that is some measure against always loading a possibly large remote addressbook. To test just enter anything in the search field, and the matching records should show up nicely. (I'm not sure if all versions allow searching for substrings. If they do, try searching for the at sign, to get a full list.)

Actually, the reason is that an LDAP server is not a database, and it is not required to return the full list of matching items of a search, if that list is sufficiently large (I believe the RFC suggests a minimum of 100 items to be returned); this is to avoid people DoSsing the LDAP server by accident. It also means that the suggestion to search for the at sign to get all items in the directory may not work.

It&aposs been some time since I got this working, but I decided to now also blog about it here now, as I was just asked it.

The main magic to get thunderbird/icedove use your ldap server as addressbook, is to include the proper schema. Search the web for mozillaAbPersonObsolete and you should find it. You do not have to use any of it&aposs new fields, not even the object class in it is needed. Your slap only have to know about the field names, then thunderbird will be able to show the normal inetorgperson&aposs mail attribute.

Some caveats, though:

You might think you might test your settings in thunderbirds by using that button to download everything and store it locally. In my experience that never works but strangly asks for a password, while the addressbook is already nicely working and needs no password at all.

Also don&apost be confused by no records shown in the new addressbook. I guess that is some measure against always loading a possibly large remote addressbook. To test just enter anything in the search field, and the matching records should show up nicely. (I&aposm not sure if all versions allow searching for substrings. If they do, try searching for the at sign, to get a full list.)

The shown fields seem also a bit strange, and differ with the different mozilla messenger/thunderbird/icedove versions. In some versions the field the primary name is extracted from can be changed, but directive to set that seems to change even more often.

Finaly, some snippet for your /etc/icedove/global-config.js, which causes all newly created users to have an addressbook as default. I forgot if all are needed or why I added them, but those that are unnecessary at least do not seem to harm. (Last tested version is the one in etch, though. Newer version might again have something changed).

   /* ldap-Server for FOOBAR */
   pref("ldap_2.autoComplete.useDirectory", true);
   pref("ldap_2.prefs_migrated", true);
   pref("ldap_2.servers.mathematik.attrmap.DisplayName", "displayName");
   pref("ldap_2.servers.default.attrmap.DisplayName", "displayName");
   pref("ldap_2.servers.mathematik.auth.savePassword", true);
   pref("ldap_2.servers.mathematik.description", "FOOBAR");
   pref("ldap_2.servers.mathematik.filename", "foobar.mab");
   pref("ldap_2.servers.mathematik.maxHits", 500);
   pref("ldap_2.servers.mathematik.uri", "ldap://HOSTNAME:389/ou=People,dc=FOOBAR,dc=TLD??sub?(mail=*)");
   

When debugging window managers or testing your X applications in other window managers, running them in an dedicated fake X server can be quite nice. While every reasonable complete window manager (even the old twm and vtwm can, and of course all of fvwm, qvwm, wmaker, ratpoison, ...) can replace itself with any other, running a window manager in a window of its own makes many things easier: single-stepping a window manager within a debugger when that debugger runs in an Xterm on the same server is no fun. And if some testing needs a more complicated setting, switching may destroy that. And it is just more comfortable to have the editor handled by your favorite WM, while you need another WM to test some aspects of an program. (It&aposs hard to see if inital sizes and layouts work well, when your WM does allow windows to choose their size. And if your WM does not have a bug another has, it&aposs easier to test a work around in the other than trying to port the bug ;-> )

So, here is some example invocation I use:

     #!/bin/sh
     Xephyr :2 -reset -terminate -screen 580x724 -nolisten tcp -xkbmap ../../../../../home/brl/.mystuff/dekeymap -auth ~/.Xauthority &
     export DISPLAY=:2
     icewm
     

Which Options are useful depends on what to use it for:

-reset -terminate means to terminate when the last child exited. This is usefull if you want it go away fast. Not usefull if you want to switch window managers without other clients running.

-screen 580x724 tells how big the window should be. This is just the size of one of my working frames, so it integrates well into my workspace. (It would be nice if Xephyr could change its resolution uppon resize of the window, though i fear programs will either be confused when the size of their X server changes unadvertised or because of too many advertisements of its changing).

-nolisten tcp as there i no need to let the world speak to your X server

-xkbmap ../../../../../home/brl/.mystuff/dekeymap I gave up figuring out how to select a German keyboard, so it justs gets 8 lines of fake description only specifing German keyboard.

-auth ~/.Xauthority tells Xephyr to require authentication. Without this everyone is allowed to control your sub X-server and all programs within it. Don&apost forget to create an token before with xauth add, though.

As one of the most often made arguments for the current Debian General Resolution about the introduction of DMs seems to be that "finding a sponsor is hard", I want to shift discussion a bit in the other direction: How about more review instead of less?

Currently only sponsored people have the privilege of having a human looking at their packages before upload. We normal DDs only have some automated tools other people wrote for us (lintian, linda, piuparts) and some self written ones (checking diffs, comparing to previous revisions and so on) and have to hope we spot all problems not yet detectable by machines ourself. What do teams and people with comaintainers do? Any chance one of the other can look over the package you generated? Is there any chance to get something like that for the rest of us? (Ideally without drawing too much manpower from the sponsorees, though in my experience slowing that down might also help, there was more than one package I could not sponsor because someone already uploaded it before even being able to write half the list of obvious problems). Perhaps some ring to review each other packages (of course best with some classification. There is often not that much sense to have someone not liking it looking into cdbs packages or vice versa).

Enrico blogged about translating the mime-types of file to a debtags, stating "I&aposm not sure it&aposs a good idea to encode mime types in debtags".

I just want to throw my two cent in here and state that I only once looked into debtooks and gave up because it does not list mime-types but some obscure other specification.

Getting suggested programs that support formats which have the same type of content like the one I want to show, to convert or to create does not help me. I most of the time do not want to edit "a video" or "a spreadsheet", but I first of all have a very specific file I want to do something with, or a specific set of formats I want to create something in. If I have a AbiWord file, Openoffice.org will not help me, and with video or audio formats it is even worse.

So after turning away disappointetly from debtags, I had to do a full mirror scan for /usr/lib/mime/packages/ files and their contents. Having that data cached in debtags would be something that really makes debtags usefull in my eyes. (And the more direct and verbatim the mime-type is encoded, the more useful it would be for me).